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Abstract 


This document describes a simple method of encapsulating Stream 
Control Transmission Protocol (SCTP) packets into UDP packets and its 
limitations. This allows the usage of SCTP in networks with legacy 
NATs that do not support SCTP. It can also be used to implement SCTP 
on hosts without directly accessing the IP layer, for example, 
implementing it as part of the application without requiring special 
privileges. 


Please note that this document only describes the functionality 
required within an SCTP stack to add on UDP encapsulation, providing 
only those mechanisms for two end-hosts to communicate with each 
other over UDP ports. In particular, it does not provide mechanisms 
to determine whether UDP encapsulation is being used by the peer, nor 
the mechanisms for determining which remote UDP port number can be 
used. These functions are out of scope for this document. 


This document covers only end-hosts and not tunneling (egress or 
ingress) endpoints. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6951. 
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Introduction 


This document describes a simple method of encapsulating SCTP packets 
into UDP packets. SCTP, as defined in [RFC4960], runs directly over 
IPv4 or IPv6. There are two main reasons for encapsulating SCTP 
packets: 


o To allow SCTP traffic to pass through legacy NATs, which do not 
provide native SCTP support as specified in [BEHAVE] and 
[NATSUPP]. 


o To allow SCTP to be implemented on hosts that do not provide 
direct access to the IP layer. In particular, applications can 
use their own SCTP implementation if the operating system does not 
provide one. 


SCTP provides the necessary congestion control and reliability 
service that UDP does not perform. 


Conventions 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


Use Cases 


This section discusses two important use cases for encapsulating SCTP 
into UDP. 


1. Portable SCTP Implementations 


Some operating systems support SCTP natively. For other operating 
systems, implementations are available but require special privileges 
to install and/or use them. In some cases, a kernel implementation 
might not be available at all. When providing an SCTP implementation 
as part of a user process, most operating systems require special 
privileges to access the IP layer directly. 


Using UDP encapsulation makes it possible to provide an SCTP 
implementation as part of a user process that does not require any 
special privileges. 


A crucial point for implementing SCTP in user space is that the 
source address of outgoing packets needs to be controlled. This is 
not an issue if the SCTP stack can use all addresses configured at 
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the IP layer as source addresses. However, it is an issue when also 
using the address management required for NAT traversal, described in 
Section 5.7. 


-2. Legacy NAT Traversal 


Using UDP encapsulation allows SCTP communication when traversing 
legacy NATs (i.e, those NATs not supporting SCTP as described in 
[BEHAVE] and [NATSUPP]). For single-homed associations, IP addresses 
MUST NOT be listed in the INIT and INIT-ACK chunks. To use multiple 
addresses, the dynamic address reconfiguration extension described in 
[RFC5061] MUST be used only with wildcard addresses in the ASCONF 
chunks (Address Configuration Change Chunks) in combination with 
[RFC4895]. 


For multihomed SCTP associations, the address management as described 
in Section 5.7 MUST be performed. 


SCTP sends periodic HEARTBEAT chunks on all idle paths. These can 
keep the NAT state alive. 


Unilateral Self-Address Fixing (UNSAF) Considerations 


As [RFC3424] requires a limited scope, this document only covers SCTP 
endpoints dealing with legacy constraints as described in Section 3. 
It doesn’t cover generic tunneling endpoints. 


Obviously, the exit strategy is to use hosts supporting SCTP natively 
and middleboxes supporting SCTP as specified in [BEHAVE] and 
[NATSUPP]. 


SCTP over UDP 
1. Architectural Considerations 


UDP-encapsulated SCTP is normally communicated between SCTP stacks 
using the IANA-assigned UDP port number 9899 (sctp-tunneling) on both 
ends. There are circumstances where other ports may be used on 
either end: As stated earlier, implementations in the application 
space might be required to use ports other than the registered port. 
Since NAT boxes might change UDP port numbers, the receiver might 
observe other UDP port numbers than were used by the sender. 
Discovery of alternate ports is outside of the scope of this 
document, but this section describes considerations for SCTP stack 
design in light of their potential use. 


Each SCTP stack uses a single local UDP encapsulation port number as 
the destination port for all its incoming SCTP packets. While the 
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uniqueness of the local UDP encapsulation port number is not 
necessarily required for the protocol, this greatly simplifies 
implementation design, since different ports for each address would 
require a sender implementation to choose the appropriate port while 
doing source address selection. Using a single local UDP 
encapsulation port number per host is not possible if the SCTP stack 
is implemented as part of each application, there are multiple 
applications, and some of the applications want to use the same IP 
address. 


An SCTP implementation supporting UDP encapsulation MUST maintain a 
remote UDP encapsulation port number per destination address for each 
SCTP association. Again, because the remote stack may be using ports 
other than the well-known port, each port may be different from each 
stack. However, because of remapping of ports by NATs, the remote 
ports associated with different remote IP addresses may not be 
identical, even if they are associated with the same stack. 


Implementation note: Because the well-known port might not be used, 
implementations need to allow other port numbers to be specified as a 
local or remote UDP encapsulation port number through APIs. 


5.2. Packet Format 


To encapsulate an SCTP packet, a UDP header as defined in [RFC0768] 
is inserted between the IP header as defined in [RFC0791] and the 
SCTP common header as defined in [RFC4960]. 


Figure 1 shows the packet format of an encapsulated SCTP packet when 
IPv4 is used. 


0 Hy 2 3 
01234567890123456789012345678<901 
+—4-+-+-4-+-4+-4-4-4+-4-t-t- 4-4 to tatitotatitotitatt-tit-4-t-t-+ 
| IPv4 Header | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 
| UDP Header | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++ 
| SCTP Common Header | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ +++ 
| SCTP Chunk #1 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++ 
P E IET el teat E E S te E 
| SCTP Chunk #n | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++ 


Figure 1: An SCTP/UDP/IPv4 Packet 
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The packet format for an encapsulated SCTP packet when using IPv6 as 
defined in [RFC2460] is shown in Figure 2. Please note that the 
number m of IPv6é extension headers can be 0. 


0 1 2 3 
Ok 2 34-5 6° 7 8° 9.0 1.2.3 4°5°6°7 8 9 0 Lt 2°93 4 56 7-8. 9 OL 
+ot-4-4-4-4F-4-4F-4-4F- 4+ t-t-ta4-ta4-t-4-t 4-4 tat tatitattat 
| IPv6 Base Header | 
+-t-4-4-4-4F-4-4F-4-4F-4-t-t-t-t-4-ti4-t-4-F-4-t tat tat tatitatta+ 

| IPv6 Extension Header #1 

+-t-4-4-4-4-4-4F-4-4F-4-+-t-4t-t-4-t-4-t-4-t 4-4 tat tatita4t-t-+ 
Mi oe a ho ee nO a 
| IPv6 Extension Header #m 

+-t-4-4-4-4F-4-F-4-4F-4-t-t-t-t-4-t-4-t-4-t-4-t tot tattatotattat 
| UDP Header | 
+-t-4-4-4-4F-4-4F-4-4F-4-t-t-t-t-4-t-4-t 4-4 4-F-4-t-t-t-tat-ta4-t+ 
| SCTP Common Header | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ HHHH 
| SCTP Chunk #1 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +H 
C ener ene Sern ere E TAN ate E. 
| SCTP Chunk #n | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 


Figure 2: An SCTP/UDP/IPv6 Packet 
5.3. Encapsulation Procedure 


Within the UDP header, the source port MUST be the local UDP 
encapsulation port number of the SCTP stack, and the destination port 
MUST be the remote UDP encapsulation port number maintained for the 
association and the destination address to which the packet is sent 
(see Section 5.1). 


Because the SCTP packet is the UDP payload, the length of the UDP 
packet MUST be the length of the SCTP packet plus the size of the UDP 
header. 


The SCTP checksum MUST be computed for IPv4 and IPv6, and the UDP 
checksum SHOULD be computed for IPv4 and IPv6. (See [RFC0768] 
regarding IPv4; see [RFC2460] and [RFC6936] regarding IPv6.) 
Although UDP with a zero checksum over IPv6 is allowed under certain 
constraints [RFC6936], this document does not specify mechanisms for 
this mode. Deployed support may be limited; also, at the time of 
writing, the use of a zero UDP checksum would be counter to the goal 
of legacy NAT traversal. 
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5.4. Decapsulation Procedure 


When an encapsulated packet is received, the UDP header is removed. 
Then, the generic lookup is performed, as done by an SCTP stack 
whenever a packet is received, to find the association for the 
received SCTP packet. After finding the SCTP association (which 
includes checking the verification tag), the UDP source port MUST be 
stored as the encapsulation port for the destination address the SCTP 
packet is received from (see Section 5.1). 


When a non-encapsulated SCTP packet is received by the SCTP stack, 
the encapsulation of outgoing packets belonging to the same 
association and the corresponding destination address MUST be 
disabled. 


5.5. ICMP Considerations 


When receiving ICMP or ICMPv6 response packets, there might not be 
enough bytes in the payload to identify the SCTP association that the 
SCTP packet triggering the ICMP or ICMPv6é packet belongs to. Ifa 
received ICMP or ICMPv6 packet cannot be related to a specific SCTP 
association or the verification tag cannot be verified, it MUST be 
discarded silently. In particular, this means that the SCTP stack 
MUST NOT rely on receiving ICMP or ICMPv6 messages. Implementation 
constraints could prevent processing received ICMP or ICMPv6 
messages. 


If received ICMP or ICMPv6 messages are processed, the following 
mapping SHOULD apply: 


1. ICMP messages with type ’Destination Unreachable’ and code ’Port 
Unreachable’ SHOULD be treated as ICMP messages with type 
"Destination Unreachable’ and code ’Protocol Unreachable’. See 


[RFC0792] for more details. 


2. ICMPv6 messages with type ’Destination Unreachable’ and code 
"Port Unreachable’ SHOULD be treated as ICMPv6 messages with type 
‘Parameter Problem’ and code ’/unrecognized Next Header type 
encountered’. See [RFC4443] for more details. 


5.6. Path MTU Considerations 


If an SCTP endpoint starts to encapsulate the packets of a path, it 
MUST decrease the Path MTU of that path by the size of the UDP 
header. If it stops encapsulating them, the Path MTU SHOULD be 
increased by the size of the UDP header. 
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When performing Path MTU discovery as described in [RFC4820] and 
[RFC4821], it MUST be taken into account that one cannot rely on the 
feedback provided by ICMP or ICMPv6 due to the limitation laid out in 


Section 5.5. 


If the implementation does not allow control of the Don’t Fragment 
(DF) bit contained in the IPv4 header, then Path MTU discovery can’t 
be used. In this case, an implementation-specific value should be 


used instead. 


7. Handling of Embedded IP Addresses 


When using UDP encapsulation for legacy NAT traversal, IP addresses 
that might require translation MUST NOT be put into any SCTP packet. 


This means that a multihomed SCTP association is set up initially as 
a single-homed one, and the protocol extension [RFC5061] in 
combination with [RFC4895] is used to add the other addresses. Only 
wildcard addresses are put into the SCTP packet. 


When addresses are changed during the lifetime of an association, the 
protocol extension [RFC5061] MUST be used with wildcard addresses 
only. If an SCTP endpoint receives an ABORT with the T-bit set, it 
MAY use this as an indication that the addresses seen by the peer 


might have changed. 
8. Explicit Congestion Notification (ECN) Considerations 


If the implementation supports the sending and receiving of the ECN 
bits for the IP protocols being used by an SCTP association, the ECN 
bits MUST NOT be changed during sending and receiving. 


Socket API Considerations 


This section describes how the socket API defined in [RFC6458] needs 
to be extended to provide a way for the application to control the 
UDP encapsulation. 


Please note that this section is informational only. 


A socket API implementation based on [RFC6458] is extended by 
supporting one new read/write socket option. 
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6.1. Get or Set the Remote UDP Encapsulation Port Number 
(SCTP_REMOTE_UDP_ENCAPS_PORT) 


This socket option can be used to set and retrieve the UDP 
encapsulation port number. This allows an endpoint to encapsulate 
initial packets. 


struct sctp_udpencaps { 
sctp_assoc_t sue_assoc_id; 
struct sockaddr_storage sue_address; 
uint16_t sue_port; 

}; 


sue_assoc_id: This parameter is ignored for one-to-one style 
sockets. For one-to-many style sockets, the application may fill 
in an association identifier or SCTP_FUTURE_ASSOC for this query. 
It is an error to use SCTP_{CURRENT|ALL}_ASSOC in sue_assoc_id. 


sue_address: This specifies which address is of interest. If a 
wildcard address is provided, it applies only to future paths. 


sue_port: The UDP port number in network byte order; used as the 
destination port number for UDP encapsulation. Providing a value 
of 0 disables UDP encapsulation. 


7. IANA Considerations 


This document refers to the already assigned UDP port 9899 (sctp- 
tunneling). IANA has updated this assignment to refer to this 
document. As per [RFC6335], the Assignee is [IESG] and the Contact 
is [IETF_Chair]. 


Please note that the TCP port 9899 (sctp-tunneling) assignment is not 
needed anymore, and IANA has removed this TCP port number assignment 
and marked TCP port 9899 as "Reserved". 


8. Security Considerations 


Encapsulating SCTP into UDP does not add any additional security 
considerations to the ones given in [RFC4960] and [RFC5061]. 


Firewalls inspecting SCTP packets must also be aware of the 
encapsulation and apply corresponding rules to the encapsulated 
packets. 


An attacker might send a malicious UDP packet towards an SCTP 
endpoint to change the encapsulation port for a single remote address 
of a particular SCTP association. However, as specified in 


Tuexen & Stewart Standards Track [Page 9] 


RFC 6951 UDP Encapsulation of SCTP Packets May 2013 


Section 5.4, this requires the usage of one of the two negotiated 
verification tags. This protects against blind attackers the same 
way as described in [RFC4960] for SCTP over IPv4 or IPv6é. Non-blind 
attackers can affect SCTP association using the UDP encapsulation 
described in this document in the same way as SCTP associations not 
using the UDP encapsulation of SCTP described here. 
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